Detailed explanation on Endpoint Communication

In general, when an endpoint classifier client first loads, it does not have an existing configuration. Once the client is up it contacts the endpoint server with an update request. The endpoint server in turn creates a list of files that the client downloads.

When the update interval passes, the client contacts the endpoint server again with the current configuration it holds, asking for available updates. The endpoint server in turn compares the client configuration to the most updated configuration it holds and creates a list of files for the client to download to bring it up to date. If the client holds the latest configuration, no files are downloaded.

Let us look at a single endpoint communicating with the endpoint server to better understand the timing intervals for the test:

Let T be the update interval as configured in the endpoint profile and let T_P be the ping interval as configured in the endpoint profile. Let t₀ be the time in which the endpoint first connects to the server. The endpoint will send a ping message to the endpoint server in (t₀+K*T_P) times and a status message to the endpoint server in (t₀+T).

We can also assume that the ping interval is much shorter than the update interval as it usually is, so T >> T_P, and during a single update interval, there are several ping intervals.

So, when ramping up N endpoints in time t₀…t_N, when (t_N-t₀) <= T, all N endpoints will complete their tasks within the update interval T. For an endpoint server to truly support an endpoint, all endpoints must complete all updates within an update interval from when they were deployed.

Adhering to the single update interval timeframe prevents overlapping that can lead to overloading the SUT and fail the test.

Since in a typical endpoint server not all clients attempt to connect at once, a uniform distribution of client actions is assumed throughout the test.

This helps to frame the different stages the SUT is in (Ramping, Idle, configuration update etc.) and verify that all tasks are completed within the update interval. (e.g., when the clients are ramping up, all simulated endpoints are registered with the endpoint server and resource download is complete for all endpoints within the timeframe of the update interval).

In general, a test run is divided to phases. Each phase can be described as an action interval, or an idle interval. Each test phase is one update interval in duration, thus keeping the system synchronized.

The phases are designed to reflect real states and action endpoint client can go through.

The phases of the test are:

1. Ramp up load to capacity – during this step all clients download the full set of configuration. By the end of this stage all client resource downloads must complete. This phase simulates the initial connection of all endpoints.
2. Idle update interval – during this step all clients require no configuration update, and only statuses, pings and incidents are being sent. This phase simulates the steady state of endpoint deployments where no configuration changes occur, and endpoint clients are connected to the endpoint server.
3. Policy change interval – during this step a policy change is triggered, and all clients download the updated policy files. This is a common case where a policy change is deployed, with no changes to other components.
4. Profile update interval – during this step an endpoint profile change is triggered, and all client download the update endpoint profile. This is common where a new endpoint profile is introduced, or an existing endpoint profile is updated.
5. Fingerprint update interval - during this step a fingerprint database change is triggered, and all client download the updated fingerprinting DB. This occurs when new elements are fingerprinted and the FPNE database needs to be updated.

During the test, the SUT VMs are monitored for CPU and memory usage, network and disk I/O and for any errors in application logs.